Hace apenas dos anios, la criptografia post-cuantica en TLS era una charla de conferencia, un experimento en ramas laterales de OpenSSL y un tema que los que no nos dedicamos profesionalmente a criptografia escuchabamos con curiosidad pero sin urgencia. En septiembre de 2025 el panorama es radicalmente distinto: los grandes operadores han puesto en produccion hibridos ML-KEM sobre conexiones reales de usuarios finales, la mayoria de trafico HTTPS en navegadores modernos ya negocia algoritmos post-cuanticos, y conviene dejar de tratar el tema como ciencia ficcion y empezar a revisar si nuestras propias infraestructuras estan preparadas.
El cambio de fase en numeros
El punto de inflexion ocurrio a partir de marzo de 2024, cuando Chrome activo por defecto el grupo X25519Kyber768 en conexiones TLS 1.3 a servidores que lo soportan. Cloudflare lo habia empezado a negociar desde septiembre de 2023 en su borde, y Apple lo incorporo a iMessage con PQ3 en febrero de 2024. Con la ratificacion de los estandares NIST en agosto de 2024, la version final paso a llamarse ML-KEM-768 y el grupo hibrido en TLS se renombro a X25519MLKEM768. Ese nombre es el que aparece hoy en los paneles de telemetria.
Los numeros publicados por Cloudflare son elocuentes. A mediados de 2025, mas del 30 por ciento de las conexiones TLS 1.3 a su borde negocian un grupo post-cuantico hibrido, y esa cifra sube por encima del 50 por ciento cuando se filtra por navegadores modernos en equipos recientes. Telemetria similar de Google y Mozilla apunta en la misma direccion. En terminos practicos, si administras un servidor web publico y tus metricas muestran grupos antiguos como X25519 o secp256r1 dominando las conexiones, tu stack se esta quedando atras respecto al resto de la web.
La otra metrica que conviene mirar es la de compatibilidad en el lado servidor. OpenSSL 3.5 incluyo ML-KEM directamente en el arbol oficial en abril de 2025, lo que significa que cualquier NGINX, Apache o HAProxy compilado contra OpenSSL 3.5 o posterior puede negociar el grupo hibrido sin parches externos. Antes de esa fecha, activar PQC requeria usar rutas como la libreria oqs-provider de Open Quantum Safe o forks experimentales como BoringSSL, y habia que vigilar cada actualizacion.
Como funciona el hibrido sin mitos
Hay un malentendido extendido que conviene aclarar. ML-KEM-768 no sustituye X25519: se combina con el en lo que se llama un intercambio hibrido. El cliente y el servidor intercambian claves usando ambos algoritmos y derivan un secreto compartido a partir de los dos. La razon es prudencia: ML-KEM es nuevo y no ha sufrido veinte anios de criptoanalisis intensivo como X25519. Si aparece un ataque clasico contra ML-KEM que no vemos hoy, el hibrido sigue siendo seguro porque X25519 sigue protegiendo. Si aparece una computadora cuantica capaz de romper X25519, el hibrido sigue siendo seguro porque ML-KEM protege.
Esta logica de defensa en profundidad es lo que ha permitido el despliegue masivo. No es apostar toda la seguridad a un algoritmo nuevo, es sumar una capa sin retirar la existente. El coste es un aumento notable de tamano del handshake, que discutire en un momento. El beneficio es que, aunque un futuro adversario almacene trafico cifrado hoy para descifrarlo manana con una computadora cuantica, el trafico hibrido de hoy sigue siendo opaco. A esto se le llama en el sector criptografia resistente a la recoleccion anticipada, o harvest now decrypt later.
El peso del handshake
El elefante en la habitacion con ML-KEM es el tamano. Una clave publica ML-KEM-768 ocupa 1184 bytes, y el ciphertext de encapsulacion otros 1088 bytes. Comparado con los 32 bytes de una clave publica X25519, eso es un aumento de dos ordenes de magnitud. En terminos practicos, un ClientHello de TLS 1.3 con X25519MLKEM768 pesa mas de dos kilobytes y puede superar el tamano de un paquete TCP estandar, forzando fragmentacion.
Esto tiene dos consecuencias notables. La primera es que redes muy agresivas con fragmentacion o middleboxes viejos pueden romper el handshake. Se han reportado casos aislados en routers domesticos antiguos, firewalls corporativos mal configurados y operadores moviles en paises concretos. La respuesta de los navegadores ha sido implementar deteccion y fallback a grupos clasicos cuando el handshake con PQC falla, lo cual funciona pero introduce latencia extra en los usuarios afectados.
La segunda es que el RTT efectivo del handshake aumenta ligeramente. Medido en conexiones modernas sobre fibra con TLS 1.3 y TLS False Start, el aumento es de pocos milisegundos y practicamente imperceptible. Medido en conexiones moviles sobre 3G en zonas con latencia alta, el aumento puede alcanzar decenas de milisegundos, lo cual si se nota. Para la mayoria de sitios eso es irrelevante. Para sitios con audiencia muy movil en zonas pobres de infraestructura, merece la pena medir antes de dar el paso.
Que revisar en una infraestructura propia
Si administras servidores web publicos, este es un buen momento para hacer una revision. Los puntos a mirar son relativamente simples. Primero, la version de OpenSSL compilada en tus servidores. Cualquier cosa por debajo de 3.5 no tiene ML-KEM nativo. Distribuciones con ciclo largo como Debian 12 todavia llevan OpenSSL 3.0, aunque Debian 13 lanzado en agosto de 2025 ya trae 3.5. En Red Hat Enterprise Linux, la situacion varia por version.
Segundo, la configuracion del servidor web. NGINX acepta grupos post-cuanticos desde la version 1.27, y aunque la configuracion por defecto suele negociarlos cuando esten disponibles, conviene verificar con el directivo ssl_groups incluyendo X25519MLKEM768 explicitamente. En Apache con mod_ssl y HAProxy es parecido: la opcion existe pero hay que asegurar que esta habilitada. Traefik, que es lo que uso en mi infraestructura, negocia automaticamente PQC cuando el OpenSSL subyacente lo soporta, sin configuracion extra.
Tercero, las metricas. Si usas Prometheus o similar, conviene anadir metricas de grupos TLS negociados para ver la proporcion real de conexiones post-cuanticas. Los exportadores modernos suelen tener esto, pero no siempre esta habilitado por defecto. Ver el numero sube es una manera concreta de confirmar que la migracion funciona.
Cuarto, las CDNs y proveedores intermedios. Si tu trafico pasa por Cloudflare, Fastly o Akamai, la negociacion PQC ocurre en el borde y tu origen no necesita cambios. Pero si tienes conexiones directas sin CDN, el esfuerzo recae en ti. Verificar esto es importante para saber donde esta el trabajo real.
Las firmas post-cuanticas son otra historia
Un matiz importante es que el despliegue actual solo cubre el intercambio de claves con ML-KEM. Las firmas digitales, que en TLS usan certificados ECDSA o RSA, siguen siendo clasicas. Los estandares NIST para firmas post-cuanticas, ML-DSA y SLH-DSA, se ratificaron en agosto de 2024, pero los certificados post-cuanticos son todavia raros. La razon es que una firma ML-DSA pesa varios kilobytes, lo cual encarece mucho un handshake que ya tiene certificados de cadena completa.
La industria esta experimentando con patrones como certificados hibridos y uso de KEMs para autenticacion, pero en septiembre de 2025 no hay consenso claro. Mi prevision razonada es que ese transito tardara dos o tres anios mas en aterrizar, porque requiere coordinacion entre autoridades de certificacion, navegadores y operadores. El intercambio de claves se pudo mover rapido porque solo requiere cooperacion entre cliente y servidor. Los certificados requieren un ecosistema completo.
Como pensar la decision
Mi lectura es que 2025 es el anio en que PQC en TLS deja de ser una opcion futurista para convertirse en higiene basica. No hacer nada no es neutral: significa que tu trafico sigue siendo susceptible al escenario de recoleccion anticipada, con un coste de oportunidad que crece cada mes mientras el resto de la web avanza. Para cualquiera que administre infraestructura critica, la pregunta no es si migrar sino cuando.
La buena noticia es que el coste de migrar es bajo. Actualizar a OpenSSL 3.5, verificar la configuracion del servidor web y anadir metricas es un trabajo de medio dia en la mayoria de infraestructuras. La mala noticia es que las autoridades de certificacion y los certificados siguen siendo clasicos, con lo que la parte de firmas del handshake queda pendiente. Pero eso es manejable mientras el intercambio de claves este cubierto.
La recomendacion concreta para quienes leeis esto y gestionais algo publico: revisad en los proximos meses, no en un anio. La ventana para hacerlo con calma se cierra rapido, y cuando el porcentaje de trafico post-cuantico pase del 50 al 80, quedarse con configuraciones heredadas empezara a ser un problema visible, no solo una debilidad teorica.
